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Abstract not available for DE 1 0353564 (A1 ) 
Abstract of corresponding document: EP 1531601 (A1) 
When data streams are being transmitted in a 
network of distributed stations (10, 20) in which the 
network subscriber stations are controlled on the 
basis of the Internet Protocol, a resource (such as a 
file) can very often be transmitted using the HTTP- 
GET method. However, this does not support 
discontinuous transmission, in sections, of data, as 
is required, for example, in the case of trick modes 
(search processes) for a video film. The invention 
describes an extension to the known HTTP-GET 
method, such that this application is likewise 
possible. For this purpose, additional parameters 
relating to the required search are transmitted to the 
source appliance (10) in the HTTP-GET request. 
The source appliance (10) then sends the respective 
data sections for the search. 
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(54) Bezeichnung: Verfahren zur abschnittsweisen, diskontinuierlichen Obertragung von Daten in einem Netzwerk 
verteilter Stationen sowie Netzwerkteilnehmerstation als Anforderungsgerat bei der Durchfuhrung eines sol- 
chen Verfahrens als auch Netzwerkteilnehmerstation als Quellgerat bei der Durchfuhrung eines solchen Ver- 
fahren 5 

(57) Zusammenfassung: Bei der Obertragung von Daten- 
stromen in einem Netzwerk verteilter Stationen (10, 20), bei 
dem die Steuerung der Netzwerkteilnehmerstationen, ba- 
sierend auf Internet-Protokoll, durchgefuhrt wird, ist es ver- 
breitet, eine Ressource (wie zum Beispiel eine Datei) mit 
der HTTP-GET-Methode zu ubertragen. Diese unterstutzt 
aber keineabschnittsweise, diskontinuierliche Obertragung 
von Daten, wie sie bei Trickmodes (Suchlaufvorgangen) 
zum Beispiel bei einem Videofilm erforderlich ist. Die Erfin- 
dung beschreibt eine Erweiterung der bekannten 
HTTP-GET-Methode, so dass diese Anwendung ebenfalls 
moglich wird. Dazu werden bei der HTTP-GET-Anforde- 
rung zusatzliche Parameter, bezogen auf den angeforder- 
ten Suchlauf, zum Quellgerat (10) ubertragen. Dieses sen- 
det dannn die jeweiligen Datenabschnitte fur den Suchlauf 
in einem HTTP-Chunked Transfer-Encoding-Modus. 
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Beschreibung 

[0001] Die Erfindung betrifft das technische Gebiet 
der Datenubertragung in einem Netzwerk verteilter 
Stationen, insbesondere in einem sogenannten 
Heirnnetzwerk. Dabei werden die Daten abschnitts- 
weise und zusatzlich auch noch diskontinuierlich, 
d.h. nicht luckenlos ubertragen. 

Hintergrund der Erfindung 

[0002] Zur Vernetzung vonGeraten im Heimbereich 
stehen mittlerweile unterschiedliche Heimnetz- 
werk-Standards zur Verfugung. 

[0003] Ein Konsortium von Unternehmen, im beson- 
deren die Unternehmen der Computer-Industrie, fe- 
derfuhrend ist Microsoft, haben eine Initiative fur die 
Spezifizierung einer Netzwerksteuersoftware basie- 
rendaufdenn existierenden Internet-Protokoll (IP)ge- 
startet. Dieses Netzwerksystem ist unter dem Kurzel 
UPnP (Universal Plug and Play) bekannt geworden. 
Bei diesem System ist die Spezifizierung nicht primar 
fur Unterhaltungselektronik-Gerate erfolgt, sondern 
es konnen in dem Netzwerk auch andere Gerate in- 
tegriert sein, insbesondere Personal Computer, 
Haushaltsgerate der weifjen Ware, wie Kuhlschran- 
ke, Mikrowellengerate, Waschmaschinen, als auch 
Heizungssteuerungen, Lichtsteuerungen, Alarmanla- 
gen und so weiter. 

[0004] Fur die Anwendung des UPnP-Verfahrens 
bei AV-Geraten wurde von einer Arbeitsgruppe des 
UPnP-Forums die UPnP-AV-Spezifikation erarbeitet, 
welche auf der allgemeinen UPnP-Spezifikation auf- 
baut und diese erweitert. Fur den Transfer von 
AV-Daten (Audio/Video Daten) in einem solchen 
Heirnnetzwerk zwischen einem sogenannten Ser- 
ver-Gerat (Quellgerat) und einem sogenannten Ren- 
derer-Gerat (Zielgerat) legt die UPnP-AV-Spezifikati- 
on fest, dass fur den Transport der Daten bekannte 
Ubertragungsprotokolle verwendet werden sollen. 
Als bekannte Protokolle werden in der Spezifikation 
die sogenannte HTTP-GET-Methode (HTTP stehtfur 
Hyper Text Transfer Protocol) und zum anderen das 
sogenannte RTP-Verfahren (RTP stehtfur Real Time 
Transport Protocol) genannt. Diese beiden Trans- 
portmechanismen stehen zur Verfugung, wenn die 
Netzwerkteilnehmerstationen uber Ethernet-Busver- 
bindungen mit einander verknupft sind. 

[0005] Das HTTP-GET-Verfahren basiert auf dem 
TCP-Verfahren (Transmission Control Protocol) wel- 
ches ein grundlegendes verbindungsorientiertes 
Transportprotokoll ist, bei dem eine gesicherte Da- 
tenubertragung (mit Fehlerkorrektur) stattfindet. Das 
TCP-Verfahren wiederum bautauf dem Internet-Pro- 
tokoll (IP) auf. Das HTTP-GET-Verfahren wurde spe- 
ziell fur die Obertragung von Dateien (z.B. 
HTML-Webseiten) von einem Webserver zu einem 



Webbrowser entwickelt. Dadurch ist es nicht ange- 
passt fur die abschnittsweise Echtzeitdatenubertra- 
gung, wie sie z. B. bei der Ubertragung von Audio- 
oder Videodatenstromen vorkommen. Andererseits 
ist das HTTP-GET-Verfahren weit verbreitet und fur 
den Anwendungsprogrammierer sehr einfach gestal- 
tet, so dass es sich g roller Beliebtheit erfreut. 

[0006] Der Transportmechanismus nach dem 
RTP-Verfahren basiert auf dem ebenfalls auf Inter- 
net-Protokoll aufbauenden UDP-Verfahren (User Da- 
tagram Protocol), welches verbindungslos arbeitet 
und keine Fehlerkorrektur verwendet, so dass bei 
Datenubertragungen nach diesem Verfahren Storun- 
gen auftreten konnen. Andererseits ist das RTP-Ver- 
fahren besser angepasst fur Echtzeitdatenubertra- 
gungen, weil es Zwischenpuffer, Zusatzzeitstempel 
und Folgenumnnern verwendet. Fur die Ubertragung 
von Audio- oder Videoinformationen ist es daher ins- 
besondere im durch zahlreiche Engpasse gekenn- 
zeichneten Internet in dieser Hinsicht besser geeig- 
net. 

[0007] Fur die Obertragung von AV-Datenstromen 
wird in der UPnP-Spezifikation der Transportmecha- 
nismus nach der HTTP-GET-Methode empfohlen. 
Die HTTP-GET-Methode war primar dazu vorgese- 
hen eine im Netzwerk vorhandene Ressource, das ist 
in vielen Fallen eine vorhandene Datei, anzufordern 
und dann vollstandig in einem Stuck zum Zielgerat zu 
ubertragen. In der HTTP Version 1.1 wurde zusatz- 
lich noch die Methode des sogenannten Chun- 
ked-Transfer-Encoding eingefuhrt, die irnmer dann 
zum Einsatz kommen soil, wenn eine Ressource zu 
ubertragen ist, von der ihre Gesamtlange zum Zeit- 
punkt des Ubertragungsbeginns noch gar nicht fest 
steht. In diesem Fall soil eine abschnittsweise aber 
kontinuierliche (d.h. luckenlose) Ubertragung der 
Ressource statt finden. 

Erfindung 

[0008] Ausgehend von dem beschriebenen Stand 
der Technik ist es Aufgabe der Erfindung den Trans- 
portmechanismus nach der HTTP-GET-Methode so 
zu erweitern, dass auch die Realisierung von soge- 
nannten Trickmodes bei der Obertragung von Daten- 
stromen moglich wird. Solche Trickmodes sind z. B. 
bei AV-Datenstromen der schnelle Vorlauf (Suchlauf 
in Vorwarts-Richtung) und der schnelle Rucklauf 
(Suchlauf in Ruckwarts-Richtung). Die Erfindung lost 
das Problem dadurch, dass fur die HTTP-GET-Me- 
thode zusatzliche Parameter definiert werden, die 
z.B. die Abspielgeschwindigkeit und Abspielrichtung 
sowie die Anfangsposition fur den Abspielvorgang 
betreffen. Fur den Abspielvorgang bei solchen Trick- 
modes werden ublicherweise nur einzelne Datenblo- 
cke benotigt, z. B. werden bei dem schnellen Such- 
lauf bei einem Videofilm wahrend des Suchlaufs nur 
einzelne Videobilder wiedergegeben und andere Vi- 
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deobilder zwischen den wiedergegebenen Bildern 
unterdruckt. Es findet also praktisch ein wiederholtes 
Springen von einem Videobild N zu einem Videobild 
N + X (Vorlauf) bzw. N - X (Rucklauf) statt. Urn dieses 
diskontinuierliche, abschnittsweise Obertragen der 
Daten zu realisieren, wird erfindungsgernali im Rah- 
men der HTTP-Get Methode der Chunked-Trans- 
fer-Encoding-Mode abgewandelt und benutzt. Es 
wird namlich immer ein wiederzugebender Datenab- 
schnitt als ein Chunk ubertragen. Dabei findet aber 
die Datenubertragung nicht kontinuierlich, also lu- 
ckenlos statt, sondern zwischen den einzelnen uber- 
tragenen Datenabschnitten sind andere Bereiche, 
die ausgelassen werden, also handelt es sich um 
eine abschnittsweise, diskontinuierliche, Datenuber- 
tragung. 

[0009] M it dieser Erfindung wird es moglich den ein- 
fachen Transportmechanismus HTTP-GET auch fur 
die Realisierung von Trickmodes bei der Echtzeitda- 
tenubertragung, insbesondere fur AV-Daten anzu- 
wenden. Ebenfalls wird es mit dieser Erfindung imog- 
lich, sogenannte Navigationsbefehle zu implementie- 
ren, die z.B. einen gezielten Sprung an eine Position 
im Datenstrom erlauben, der eine gewisse Zeit, z.B. 
1 5 Minuten spater als die aktuelle Spielzeit liegt. 

[0010] Durch die in den abhangigen Anspruchen 
aufgefuhrten Maflnahmen sind vorteilhafte Weiterbil- 
dungen und Verbesserungen des erfindungsgema- 
fien Verfahrens moglich. 

[0011] Als Ruckmeldung, dass die Parameter in der 
erfindungsgemafien HTTP-GET-Anforderung richtig 
interpretiert werden konnten, kann entweder ein ver- 
einbarter Spezial-Statuskode zuruckgeliefert werden 
oder aber es werden die Parameter in der Ruckant- 
wort noch mal wiederholt. Bei einem nicht erfindungs- 
gemaft ausgelegten Gerat wurde die Ruckantwort 
anders ausfallen, so dass das Anforderungsgerat 
eine geeignete Information an die Bedienperson aus- 
geben kann, wenn das angesprochene Gerat die 
Trickmode-Wiedergabe so nicht unterstutzt. 

[0012] Entsprechend vorteilhafte Mafinahmen fur 
eine Netzwerkteilnehmerstation als Anforderungsge- 
rat bei der Durchfuhrung des erfindungsgemaften 
Verfahrens sind in den Anspruchen 10 und 11 aufge- 
listet. 

[0013] Entsprechend vorteilhafte Maftnahmen fur 
eine Netzwerkteilnehmerstation als Quellgerat bei 
der Durchfuhrung des erfindungsgemaflen Verfah- 
rens sind in den Anspruchen 12 bis 1 6 aufgelistet. 

Zeichnungen 

[0014] Ausfuhrungsbeispiele der Erfindung sind in 
den Zeichnungen dargestellt und werden in der nach- 
folgenden Beschreibung naher erlautert. Es zeigen: 



[0015] F]£Ll die groben Block-Schaltbilder eines 
Quell- und Zielgerates in einem Netzwerk verteilter 
Stationen; 

[0016] FigJSdas Format einer erfindungsgemafien 
HTTP-GET-Anforderung, die vom Zielgerat zum 
Quellgerat gesendet wird; 

[0017] Fl&JI ein Beispiel einer Universalfernbedie- 
nung; 

[001 8] Fig, 4 eine schematische Darstellung, die als 
Beispiel einen Dreifach-Suchlauf in Vorwarts-Rich- 
tung bei MPEG2 kodierten Videodaten zeigt; 

[0019] Fig. 5 das Format der erfindungsgemaften 
HTTP-GET-Antwort; 

[0020] Fig^ ein Ablaufdiagramm fur ein Programm 
mit dem die HTTP-GET-Anforderung erstellt und zum 
Quellgerat gesendet wird; 

[0021] Fk^JL das Ablaufdiagramm eines Pro- 
gramms welches im Quellgerat abgearbeitet wird zur 
Erstellung und Aussendung der HTTP-GET-Ruckan- 
wort im Chunked-Transfer-Encoding Mode; und 

[0022] Fjg^S das Aussenden einer HTTP-GET-An- 
forderung vom Zielgerat zum Quellgerat mit Angabe 
einer absoluten URL, die durch Fragezeichen abge- 
trennt ebenfalls die erforderlichen Parameter fur den 
angeforderten Abspielvorgang enthalt. 

Beschreibung der Erfindung 

[0023] Fjg^l zeigt ein Quellgerat 10 und ein Zielge- 
rat 20 in einem Netzwerk verteilter Stationen. Wie 
dargestellt, sollen die einzelnen Netzwerkteilnehmer- 
stationen durch Ethernet-Busverbindungen 15 mit- 
einander verbunden sein. Weiterhin wird angenom- 
men, dass die einzelnen Netzwerkteilnehmerstatio- 
nen gemaft des UPnP-Standards ausgelegt sind. Die 
UPnP-Spezifikation kann uber die Firma Microsoft 
bezogen werden. 

[0024] Nahere Informationen sind auch auf deroffi- 
ziellen Internetseite fur das UPnP-System vorhan- 
den. Diesbezuglich wird auf die Internetseite 
www.UPnP.org hingewiesen. 

[0025] Das Quellgerat entspricht in der Terminolo- 
gie des UPnP-Systems einem Server-Gerat. Das 
Zielgerat 20 entspricht in der Terminologie des UP- 
nP-Systems einem Renderer-Gerat, entsprechend 
Zielgerat. Im dargestellten Beispiel gernaft Eigji 
sind fur das Quellgerat 10 die zwei wesentlichen 
Komponenten Speichereinrichtung 12 und 
HTTP-Server 11 gesondert hervorgehoben. Typische 
Quellgerate fur AudioA/ideodaten sind z. B. 
DVD-Spieler, DVD-Rekorder, Festplatten-Rekorder, 
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DVHS-Rekorder, CD-Spieler, MP3-Spieler, Videoka- 
mera oderauch ein Personal Computer. Dieabspiel- 
baren AV-Daten sind im Quellgerat 10 in derSpeiche- 
reinrichtung 1 3 gespeichert Die Komponente 
HTTP-Server 11 istgemaft UPnP-Spezifikation zwin- 
gend fur ein solches UPnP-Gerat vorgesehen. Die 
Komponente kann mit Softwaremitteln realisiert sein. 
Die entsprechenden Programm-Methoden sind ajs 
dem Stand der Technik bekannt und es wird im Hin- 
blickauf die Offenbarung dieser Komponenten insbe- 
sondere auf die UPnP-Spezifikation verwiesen. 

[0026] Die wesentlichen Komponenten im Zielgerat 
20 sind ein HTTP-Sende+Empfangsgerat 22, 
HTTP-Se rver 21, Pufferspeicher 23, und eine Deko- 
dierlogik 24. Als Zielgerate 20 kommen beispielswei- 
se ein digitales Fernsehgerat, dieses kann auch in 
Form einer Set-Top-Box realisiert werden, ein 
DVD-Abspielgerat, ein MP3-Player und auch ein Per- 
sonal Computer in Frage. Bei der Ubertragung von 
MPEG2 kodierten Videoinformationen muss die De- 
kodiereinheit 24 als MPEG2-Dekoderausgelegt sein. 
Der Pufferspeicher 23 soil vorzugsweise als 
RAM-Speichereinheit realisiert werden. 

[0027] Im Folgenden wird angenommen, dass zwi- 
schen Quellgerat und Zielgerat eine eingerichtete 
Verbindung fur eine Datenubertragung von AV-Daten 
besteht. Weiterhin wird angenommen, dass das 
Quellgerat 10 einen Videofilm mit Normalgeschwin- 
digkeit abspielt und den zugehorigen AV-Datenstrom 
kontinuierlich uber die eingerichtete Verbindung zu 
dem Zielgerat 20 ubertragt. So dann fordert der Be- 
nutzer beim Zielgerat 20 einen schnellen Suchlauf in 
Vorwarts-Richtung an. Dies kann, wie in FLgJS ge- 
zeigt, mit einer Fernbedienung 30 erfolgen. In FjjjJi 
ist als Beispiel eine Universal-Fernbedienung ge- 
zeigt, die mit Touch-Screen-Display 31 ausgestattet 
ist, auf dem die Bedienfunktionen fur einen digitalen 
Videorekorder angezeigt sind. Solche Univer- 
sal-Fernbedienungen sind aus dem Stand der Tech- 
nik bekannt. Als Beispiel wird auf die altere europai- 
sche Patentanmeldung EP-A-0 780 990 hingewie- 
sen. Die auf dem Display 31 dargestellten Tasten 
sind eine Stopp-Taste 32, eine Wiedergabetaste 33, 
eine Pausentaste 34, eine Aufnahmetaste 34, eine 
Taste fur schnellen Rucklauf 36, eine Taste fur 
schnellen Vorlauf 37, eine Taste fur einen Vor- 
warts-Titelsprung 38 sowie eine Taste fur einen 
Ruckwarts-Titelsprung 39. Die Bedienperson hatto 
den schnellen Vorwarts-Suchlauf durch Drucken der 
Taste 37 beim Zielgerat 20 angefordert. Dieses Kom- 
mando wird dann vom Zielgerat 20 in eine entspre- 
chende HTTP-GET-Anforderung umgewandelt und 
iiber das Netzwerkkabel 15 zu dem Quellgerat ge- 
sendet. Die genaue Struktur der HTTP-GET-Anforde- 
rung ist in der Fig.,2 angegeben . In dem dortgezeig- 
ten Beispiel steht nach dem Schlusselwort GET der 
angeforderte Dateiname. Dies ist durch den Parame- 
ternamen ITEM signalisiert. Zum Beispiel lautet der 



Dateiname MenlnBlack.MPG was einem typischen 
Namen fur einen Videofilm entspricht. Nach der 
HTTP-Versionsangabe in derselben Zeile folgt in der 
nachsten Zeile die Angabe in welchem Gerat diese 
Datei zu finden ist. Zur Kennzeichnung dieses Para- 
meters ist in der zweiten Zeile der Ausdruck HOST 
dem Servernamen vorangestellt. Der im Beispiel an- 
gegebener Servername lautet www.my.server. In der 
darauf folgenden Zeile steht als nachster Parameter 
die Angabe der Abspielgeschwindigkeit. Der Para- 
metername ist entsprechend AV_SPEED. Dieser Pa- 
rameter beinhaltet aber gleichzeitig auch die Abspiel- 
richtung. Im dargestelltem Beispiel besteht die Para- 
meterangabe in dem Ausdruck Forward_3 was be- 
deutet, dass der schnelle Suchlauf in Vorwarts-Rich- 
tung mit dreifacher Geschwindigkeit stattfinden soil. 
Fur die Abspielrichtung konnte aber auch ein separa- 
ter Parameter zusatzlich eingefuhrt werden. 

[0028] In der vierten Zeile der HTTP-GET-Anforde- 
rung ist noch die Parameterangabe fur die Anfangs- 
position des angeforderten Suchlaufs angegeben. 
Der Parametername hierfur ist AV STARTTIME. 
Nach dem Parameternamen steht dann die Positi- 
onsangabe 01 .02.03.02. Dies gibt die aktuelle Spiel- 
zeitposition an, namlich eine Stunde, 2 Minuten, 3 
Sekunden, Bild 02. Fur die Erstellung der 
HTTP-GET-Anforderung ist im Zielgerat 20 ein ent- 
sprechendes Programm vorgesehen, welches nach 
Anforderung des Suchlaufvorgangs (ausgelost durch 
Drucken der Taste 37 abgearbeitet wird). Dieses wird 
nachfolgend noch naher erlautert. 

[0029] In der £1^4 ist jetzt der angeforderte Such- 
laufvorgang mit dreifacher Abspielgeschwindigkeit in 
Vorwarts-Richtung naher dargestellt. Gezeigt ist die 
Darstellungsreihenfolge von digital kodierten Video- 
bildern, wobei die digitalen Videobilder nach dem 
MPEG2-Standard kodiert sind. In diesem Standard 
wird zwischen intra-kodierten Bildern (l-Bilder) bidi- 
rektional-kodierten Bildern (B-Bilder) sowie unidirek- 
tional-kodierten Bildern (P-Bilder) unterschieden. Die 
hochste Datenkompressionsrate weisen die B-Bilder 
auf, gefolgt von den P-Bildern. Die intra-kodierten Bil- 
der sind am wenigsten komprimiert, konnen dafur 
aber auch als Stutz-Bilder dienen, d.h. ihr Bildinhalt 
kann ohne Kenntnis eines vorhergehenden oder 
nachfolgenden Bildes rekonstruiert werden. Im 
MPEG2-Standard ist eine Abfolge von Bildern als so- 
genannte Group of Pictures GOP empfohlen. Diese 
lautet IBBPBBPBBPBB. Rq, 4 zeigt drei aufeinander 
folgende solche Bildgruppen. Fur die Realisierung 
des Dreifach-Suchlaufs in Vorwarts-Richtung wird 
jetzt wie folgt vorgegangen: Es werden nur die l-Bil- 
der und P-Bilder der Bildgruppen wiedergegeben. 
Dadurch werden aus einer Bildgruppe mit 12 Bildern 
vier verschiedene Bilder dargestellt, sodasssich ins- 
gesamt ein Dreifach-Suchlauf in Vorwarts-Richtung 
ergibt. Bei dem Suchlauf wird also von l-Bild zu 
P-Bild, P-Bild zu P-Bild bzw. von P-Bild zu l-Bild im 
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Datenstrom gesprungen. 

[0030] Fur weitere Details zu der Technik, wie bei 
MPEG2 codierten Videobildern Trickmodes realisier- 
bar sind, wird auf den Artikel „Entwicklung eines 
DVD-Players: Probleme und Losungen" von Ingo 
Hutter und Dirk Adolph in FKT Nr. 11/1999 Seiten 
664ff verwiesen. 

[0031] EMJk zeigt das Format der HTTP-Ruckan- 
wort die vom Quellgerat 10 ausgegeben wird, nach- 
dem der schnelle Suchlauf angefordert worden ist. In 
der ersten Zeile wird die Statusmeldung fur eine er- 
folgreich eingetroffene HTTP-GET-Anforderung ge- 
liefert. Darin befindet sich auch die Versionsangabe 
bezuglich des HTTP-Verfahrens. In der zweiten Zeile 
der Ruckantwort wird das Datum und die Uhrzeit an- 
gegeben. 

[0032] In der dritten Zeile wird uber das Schlussel- 
wort CONTENT-TYPE signalisiert, welcher Datentyp 
nachfolgend ubertragen wird. Inn genannten Beispiel 
handelt es sich urn Videodaten, kodiert im 
MPEG2-Format. Mit der vierten Zeile wird dann sig- 
nalisiert, dass die nachfolgende Ubertragung im 
Chunked Transfer-Encoding-Mode stattfinden wird. 
Anschlieftend wird der erste Datenabschnitt gesen- 
det. Vorangestellt ist die Langenangabe des betref- 
fenden Datenabschnittes in Hexadezimalzahlen. Da 
wie zuvor im Zusammenhang mit R^_4 erlautert nur 
die Daten der I-, und P-Bilder fur den Suchlauf uber- 
tragen werden, folgen hier jeweils als ein Datenab- 
schnitt die Videodaten eines l-Bildes. Fur ein Stan- 
dardvideobild betragt die Datengrofle eines solchen 
l-Bildes zirka 120 KByte. Dies schwankt naturlich von 
Bildinhalt zu Bildinhalt. Durch Semikolon abgetrennt 
von der Langenangabe folgt in derselben Zeile noch 
die jeweilige Zeitangabe fur das ubertragene Video- 
bild. Der Suchlauf wurde mit der Anfangszeitangabe 
01:02:03:02 angefordert, siehe FjgJL Das Quellge- 
rat 10 hat ausgehend von dieser Zeitangabe das 
nachstfolgende l-Bild ausgesucht. Dieses wurde bei 
der Zeitposition 01:02:03:04 gefunden. Deshalb ent- 
spricht die Zeitangabe in der funften Zeile der 
HTTP-Get-Ruckanwort genau diesem Wert. In den 
nachsten Zeilen folgen dann die Videodaten fur das 
angekundigte l-Bild. Nachdem dieses Videobild uber- 
tragen worden ist, folgt in der darauffolgenden Zeile 
die Langenangabe fur das nachste zu ubertragende 
Videobild mit der entsprechenden Zeitangabe an wel- 
cher Position im Videofilm dieses Bild lokalisiert ist. 
Die zugehorigen Videodaten folgen danach. Fj&JS 
zeigt dann noch die entsprechenden Angaben fur das 
dritte angesprungene P-Bild das danach ubertragen 
wird. DerVorgang setzt sich weiterfort, bisentweder 
der Suchlauf durch Benutzersteuerung beendet wird 
oder bis das Ende des Videofilms erreicht ist. Das 
Ende der Datenubertragung im Chunked Trans- 
fer-Encoding-Mode wird mit einer Zeile angezeigt, 
die lediglich als Wert den Wert 0 ubertragt. Dieses ist 



ebenfalls in FjMsA ersichtlich. 

[0033] Wie beschrieben, handelt es sich urn eine 
abschnittweise aber diskontinuierliche Ubertragung 
der Videodaten gemaft der Erfindung. Diskontinuier- 
lich deshalb, weil nur die Videodaten einzelner Bilder, 
hier der I- und P-Bilder, ubertragen werden, hingegen 
die Videodaten der dazwischen liegenden Bilder 
nicht ubertragen werden. 

[0034] Da es durchaus moglich ist, dass eine erfin- 
dungsgemafte HTTP-Anforderung an ein Gerat ge- 
sendet wird, das keine Trickmodi der beschriebenen 
Art unterstutzt, sollte von einem Trickmodi unterstut- 
zenden Gerat in der Ruckantwort deutlich gemacht 
werden, dass die Anforderung verstanden wurde und 
der Datenstrom konform zu den Parametern in der 
Anfrage ist. Dies konnte geschehen durch einen spe- 
ziellen HTTP-Statuskode in der Ruckantwort (z.B. 
„21 0", „Trickmode OK"), wie in FjaJI gezeigt. 

[0035] Alternativ kann in der Ruckantwort auch eine 
Wiederholung der Trickmodeparameter erfolgen urn 
Dieses anzuzeigen. Die Ruckantwort ware dann wie 
folgt aufgebaut: 
HTTP/1.1 200 OK 

Date: Fri, 31 Dec 2003 17:59:59 GMT 
Content-Type: video/mpeg 
Transfer-Encoding: chunked 
AV_SPEED: forward_3 
AVSTARTTIME: 01.02.03.04 
1EAE0; time=01:02:03:04 

[0036] In dieser Ruckantwort wird einfach der be- 
kannte Statuskode 200 OK verwendet. Aber dafur 
werden ja die Trickmodeparameter wiederholt, was 
kein Standard-Gerat machen wurde, wenn es die 
Trickmodeparameter nicht interpretieren kann. Bei 
der Angabe des Parameters AV STARTTIME wurde 
die Zeitangabe in Ubereinstimmung gebracht mit 
dern Wert, der zu dem ersten ubertragenen Videobild 
gehort. Dies ist optional. Es kann auch einfach nur 
die Zeitangabe der Anforderung wiederholt werden. 

[0037] FigJS zeigt ein Beispiel eines Ablaufdia- 
gramms fur ein Programm das im Zielgerat 20 abge- 
arbeitet wird, nachdem der schnelle Suchlaufvorgang 
vom Benutzer angefordert wurde. Das Programm 
startet mit dem Prograrnmschritt 40, nach dem die 
Bedienperson die Vorwarts-Suchlauftaste 37 betatigt 
hat. Da zuvor bereits ein Videofilm in Normalge- 
schwindigkeit abgespielt wurde, konnen im nachfol- 
genden Prograrnmschritt 41 die erforderlichen Para- 
meter fur den Suchlaufvorgang noch von dem laufen- 
den Videofilm extrahiert werden. Diese sind zum ei- 
nen die Zeitangabe fur die aktuelle Spielzeit, der Da- 
teiname des wiedergegebenen Films, der Name des 
Servers auf dem der Videofilm gespeichert ist. Zu- 
satzlich wird auch noch ein Parameter fur den neuen 
Betriesmode erfasst. In einem einfachen Fall kann 
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dieser Parameter fest mit der Betatigung der Such- 
lauftaste 37 verbunden sein. Dieser Taste ist dann 
fest der Parameter Vorwarts Suchlauf (dreifach) zu- 
geordnet. 

[0038] Im nachsten Prograrnmschritt 42 wird die 
Normalwiedergabe des laufenden Videofilms ge- 
stoppt. Im anschlielienden Prograrnmschritt 43 wird 
der Pufferspeicher 23, dernoch Daten weitererVide- 
obilder enthalten kann, geloscht. Durch diese Maft- 
name wird erreicht, dass ein dedizierter Ubergang 
von Normalwiedergabe zur Suchlaufwiedergabe 
stattfindet, und zwar ohne groftere Verzogerungszeit, 
die gegebenenfalls als storend empfunden werden 
kann. 

[0039] Im darauf folgenden Prograrnmschritt 44 er- 
stellt das Programm die notige HTTP-GET-Anforde- 
rung fur den schnellen Suchlaufvorgang. Das Format 
der zu erstellenden Anforderung ist in der Fig. 2 ge- 
zeigt. Diese HTTP-GET-Anforderung wird in dem 
Prograrnmschritt 45 an das Quellgerat 10 gesendet. 
Danach endet dieser Programmteil im Prograrnm- 
schritt 46. 

[0040] FigL_7 zeigt ein Beispiel eines Ablaufdia- 
granfims fur ein Programm das im Quellgerat nach 
Eingang der beschriebenen HTTP-GET-Anforderung 
abgearbeitet wird. Der Start des Programms ist mit 
Prograrnmschritt 50 bezeichnet. Dieser wird durch 
Eingang des zuvor beschriebenen HTTP-GET-Re- 
quests ausgelost. In dem Prograrnmschritt 51 wird 
der eingegangene HTTP-GET-Request ausgewertet. 
Es werden die darin ubertragenen Parameter insbe- 
sondere Anfangsposition fur den neuen Abspielvor- 
gang, File Name, Server Name, sowie Betriebsmode, 
d.h. Suchlauf mit welcher Geschwindigkeit in Vor- 
warts- oder Ruckwarts-Richtung aus der 
HTTP-GET-Anforderung extrahiert. Das Beenden 
des laufenden Abspielvorgangs erfolgte automatisch 
nach Ubertragung der HTTP-GET-Anforderung 
durch die bestehende TCP/IP-Verbindung bei dem 
Prograrnmschritt 42. Ausgehend von der ubermittel- 
ten Ausgangsposition wird im nachsten Prograrnm- 
schritt 52 das darauf folgende l-Bild gesucht. Der 
neue Abspielvorgang startet dann bei dem so gefun- 
denen l-Bild. Die dafur gelesenen Videodaten wer- 
den in eine HTTP-Antwortbotschaft eingebunden. 
Das Format der HTTP-Antwortbotschaft ist wie in der 
Fj&Jii gezeigt. Es wird also der HTTP-Chunked 
Transfer-Encoding-Mode benutzt. Dieser Schritt ist 
im Programm der FMJL mit der Bezugszahl 53 be- 
zeichnet. Nach dem die Videodaten des ausgewahl- 
ten l-Bildes ubertragen worden sind, springt das 
Laulwerk des Quellgerates 10 die Stelle des nachs- 
ten darauf folgenden l-Bildes in der Videodatendatei 
an. Dafur sind gemaft MPEG2-Standard separate 
Zeigerinformationen im Videodatenstrom enthalten. 
Die Daten des nachsten l-Bildes werden dann als 
nachstes zu dem Zielgerat 20 ubertragen. Dieser 



Vorgang wiederholt sich fortlaufend so lange, bis ent- 
weder die Verbmdung vom Zielgerat unterbrochen 
wurde oder bis zum Ende des Videofilms. Dann wird 
die in FSq. 7 gezeigte Endlos-Schleife wird Durchbro- 
chen. 

[0041] Eine alternative Ausfuhrungsform fur eine 
HTTP-GET-Anforderung gemaU der Erfindung ist in 
der FisLjS dargestellt. Erfindungsgemaft beinhaltet 
der darin gezeigte Pfadname nicht nur den Dateina- 
men, sondern auch alle weiteren erforderlichen Para- 
meter fur den neu zu startenden Suchlauf. Das Bei- 
spiel ist so ausgefuhrt, dass samtliche erforderlichen 
Parameter in dem Pfad nach einem Fragezeichen 
aufgelistet sind. Gezeigt sind die Parameter Dateina- 
me, Abspielgeschwindigkeit und Richtung sowie An- 
fangsposition. Mit dem Fragezeichensymbol konnen 
in einer URL (Uniform Resource Locator) eigene de- 
finierte Parameter durch &-Symbol getrennt an den 
Server ubergeben werden. Dieses Verfahren ist in 
dem Internet Technologie-RFC 1738 naher beschrie- 
ben (RFC steht fur Request For Comment). 

[0042] Die Erfindung kann nicht nur fur die Realisie- 
rung von Trickmodes (Suchlaufen) bei der Ubertra- 
gung von AV-Daten eingesetzt werden. Solche Such- 
laufe sind auch moglich bei anderen Multimediada- 
ten. Als Beispiel wird eine Datei erwahnt, in der der 
Inhalt eines Buches gespeichert ist. 

[0043] Weiterhin ist die Erfindung nicht nur auf den 
Anwendungsfall der Durchfuhrung eines Trickmodes 
(Suchlauf) beschrankt. Damit lassen sich auch typi- 
sche Navigationsvorgange ? wie zum Beispiel das 
Springen in Dokumenten an eine angegebene Positi- 
on (z. B. an eine Position 15 Minuten spater in dem 
Datenstrom realisieren). In diesem Fall wurde in der 
HTTP-GET-Anforderung als Geschwindigkeitsanga- 
be fur die Wiedergabe Normalwiedergabe angege- 
ben aber die neue Anfangsposition ware entspre- 
chend die Position 15 Minuten spater im Datenstrom. 

[0044] Weiterhin kann die Zahl und Art der erforder- 
lichen Parameter je nach Ausfuhrungsform variieren. 
Beispielsweise muss nicht immer die Anfangspositi- 
on als Parameter ubergeben werden, wenn eine be- 
stimmte Anfangsposition fest vorgegeben ist. Bei ei- 
nem kurzen Beitrag kann vorgegeben sein, dass der 
Vorwartssuchlauf jedes Mai von derabsoluten Start- 
position erfolgen soil. 

Patentanspruche 

1. Verfahren zur abschnittsweisen, diskontinuier- 
lichen Ubertragung von Daten in einem Netzwerk 
verteilter Stationen zwischen einer ersten (10) und 
zweiten Netzwerkteilnehmerstation (20), gekenn- 
zeichnet durch die folgenden Schritte: 
-Erstellen einer HTTP-GET-Anforderung mitAngabe 
der erforderlichen Parameter, wie Dateiname, Datei- 
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typ, Pfad, Abspielgeschwindigkeit, Abspielrichtung, 
Anfangsposition, 

- Senden der HTTP-GET-Anforderung an das Quell- 
gerat (10) 

- abschnittsweises, diskontinuierliches Obertragen 
der Daten von dem Quellgerat (10) zu dem Zielgerat 
(20) im Modus des HTTP-Chunked Transfer-Enco- 
ding. 

2. Verfahren nach Anspruch 1, wobei in der 
Ruckantwort fur die Ubertragung der angeforderten 
Daten ein bestirnmte Statuskode zuruckgeliefert 
wird,dersignalisiert, dassdie erforderlichen Parame- 
ter in der HTTP-GET-Anforderung richtig interpretiert 
werden konnten. 

3. Verfahren nach Anspruch 1 Oder 2, wobei in 
der Ruckantwort fur die Ubertragung der angeforder- 
ten Daten der/die erforderlichen Parameter von der 
HTTP-GET-Anforderung wiederholt werden, als 
Ruckmeldung, dass die erforderlichen Parameter in 
der HTTP-GET-Anforderung richtig interpretiert wer- 
den konnten. 

4. Verfahren nach einem der vorhergehenden 
Anspruche 1 bis 3, wobei die abschnittsweise, dis- 
kontinuierliche Ubertragung der Daten im Fall der An- 
forderung eines schnellen Suchlaufs eingesetzt wird. 

5. Verfahren nach einem der Anspruche 1 oder2, 
wobei die Daten Multimediadaten betreffen, insbe- 
sondere Audio- oder Videodaten. 

6. Verfahren nach einem der vorhergehenden 
Anspruche, wobei zur abschnittsweisen, diskontinu- 
ierlichen Ubertragung im HTTP-Chunked Trans- 
fer-Encoding-Modus, jeweils ein Abschnitt der Video- 
daten, insbesondere die Daten eines Videobildes, mit 
Angabe der Datenlange als Block ubertragen wer- 
den. 

7. Verfahren nach Anspruch 6, wobei bei einem 
MPEG2-kodierten Videofilm jeweils die Daten der in- 
trakodierten Videobilder oder der unidirektional ko- 
dierten Videobilder als ein Datenabschnitt ubertragen 
werden. 

8. Verfahren nach einem der vorhergehenden 
Anspruche, wobei das Netzwerk verteilter Stationen 
ein auf Internet-Protokoll-Basis gesteuertes Netz- 
werk ist. 

9. Verfahren nach Anspruch 8, wobei die Netz- 
werkteilnehmerstationen (10, 20) zurSteuerung nach 
der UPnP-Spezifikation ausgelegt sind, wobei UPnP 
fur Universal Plug and Play steht. 

1 0. Netzwerkteilnehmerstation als Anforderungs- 
gerat bei der Durchfuhrung des Verfahren nach ei- 
nem der vorhergehenden Anspruche, gekennzeich- 



net durch Programmmittel zum Erstellen einer 
HTTP-GET-Anforderung mit Angabe der erforderli- 
chen Parameter fur ein abschnittsweises, diskontinu- 
ierliches Obertragen der Daten, wie Dateiname, Da- 
teityp, Pfad, Abspielgeschwindigkeit, Abspielrich- 
tung, Anfangsposition auf Anforderung hin. 

11. Netzwerkteilnehmerstation nach Anspruch 
10, mit Mitteln zum Empfang eines Befehls fur die 
Durchfuhrung eines schnellen Suchlaufvorgangs und 
Mitteln zum Aktivieren der Programmmittel zum Er- 
stellen der HTTP-GET-Anforderung daraufhin. 

12. Netzwerkteilnehmerstation als Quellgerat bei 
der Durchfuhrung des Verfahrens nach einem der 
Anspruche 1 bis 9, gekennzeichnet durch Programm- 
mittel zum Auswerten einer empfangenen 
HTTP-GET-Anforderung von einem Zielgerat (20) fur 
die abschnittsweise, diskontinuierliche Ubertragung 
von Daten mit Angabe der erforderlichen Parameter 
wie Dateiname, Dateityp, Pfad, Abspielgeschwindig- 
keit, Abspielrichtung, Anfangsposition und Mitteln 
zum abschnittsweisen, diskontinuierlichen Senden 
der angeforderten Daten zu dem Zielgerat (20) im 
Modus des HTTP-Chunked Transfer-Encoding. 

1 3. Netzwerkteilnehmerstation nach Anspruch 
12, wobei im Fall der Ubertragung von MPEG-Video- 
daten Mittel vorgesehen sind, die im Rahmen des 
HTTP-Chunked-Transfer-Encoding die Daten derint- 
ra-kodierten Videobilder oder der unidirektional ko- 
dierten Videobilder des MPEG-Videodatenstromes 
als separate Datenabschnitte ubertragen. 

14. Netzwerkteilnehmerstation nach Anspruch 
12 oder 13, wobei die Mittel zum abschnittsweisen, 
diskontinuierlichen Senden der Daten jeweils auch 
eine Positionsangabe hinzufugen, die die Stellung 
des Datenabschnitts im Datenstrom angibt. 

15. Netzwerkteilnehmerstation nach einem der 
Anspruche 12 bis 14, wobei Formatierungsmittel vor- 
gesehen sind, die in der Ruckantwort fur die Ubertra- 
gung der angeforderten Daten einen bestimmten 
Statuskode zuruckliefern, der signalisiert, dass die 
erforderlichen Parameter in der HTTP-GET-Anforde- 
rung richtig interpretiert werden konnten. 

16. Netzwerkteilnehmerstation nach einem der 
Anspruche 12 bis 15, wobei Formatierungsmittel vor- 
gesehen sind, die in der Ruckantwort fur die Ubertra- 
gung der angeforderten Daten den/die erforderlichen 
Parameter von der HTTP-GET-Anforderung wieder- 
holen, als Ruckmeldung, dass die erforderlichen Pa- 
rameter in der HTTP-GET-Anforderung richtig inter- 
pretiert werden konnten. 

Es folgen 4 Blatt Zeichnungen 
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Fig.1 
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HTTP Get Request 



Get/item/MenlnBlack.mpg HTTP/1.1 
Host:www.my.server 
AV-SPEED: forward_3 
AV_STARTTIME: 0102.03.02 
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Fig.2 
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Fig.4 
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HTTP/1.1 210Trickmode OK 

Date: Fri, 31 Dec 2003 17:59:59 GMT 

Content-Type: video / mpeg 

Transfer-Encoding: chunked 

1EAEO; time =01:02:03:04 

I - Frame-Data 

OCE5B;time =01:02:03:07 

P - Frame-Data 

OAB3A; time =01:02:03:10 

P - Frame-Data R 9- 5 
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Fig.6 
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Gen HTTP Chunk' 
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Fig.7 




HTTP GET Request (URL) 




GET / item?name = MenlnBlack&speed=forward_3&time=01 .02.03.02 HTTP/1-1 
HOST: www.my.server 

Fig.8 
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